简单聊聊Radius的PEAP协议 |
您所在的位置：网站首页 › radius coa相关协议 › 简单聊聊Radius的PEAP协议 |
简单聊聊Radius的PEAP协议
| 简单聊聊Radius的PEAP协议
简述：radius协议很少有人知道，但是生活中还是很常使用的。先看看他的wiki上面是怎么说的 RADIUS（Remote Authentication Dial In User Service） 用户远程拨入认证服务，它主要针对的远程登录类型有：SLIP、PPP、telnet和rlogin等。RADIUS协议应用范围很广，包括普通电话、上网业务计费，对VPN的支持可以使不同的拨入服务器的用户具有不同权限。 EAP协议：可扩展的网络认证协议，这个就是我认为网络工程师最取巧的地方，好我给你一个可扩展的键值，这个键值在我的字典中的键值是79，79内我分给你一个位的长度（也就是FF 255的长度），你随便玩儿吧，放啥随你，只要我认得。 现在常用的是PEAP的协议进行radius认证处理。首先看这个名词就知道，它是一个EAP协议的扩展，进行protect的EAP协议。这的P是最坑的地方，鬼知道他们是怎么想的把P用TLS协议进行保护的处理。我的天，抓狂中....... 言归正传，我们开始抓包咯： 
PEAP-wireshak
上面可以看到相关的请求（这么多包....） 我们先看第一个包： 
2
可以看到在EAP中出现了 |code|id|Length|Type|identity| | 1 |1 |1 2 |1 | | 在上面identity一般是username 这个时候是告诉radius服务器我需要对你发送这个的认证请求，请准备处理对于这个包中的Message-Authenticator是对包完整性检测的一个值，服务端或者客户端生成一个发送过去，服务端或者客户端收到后先进行验证一遍，再进行其他的业务处理 
3
radius服务器会给你mschap-v2的响应（在后面的讲解中会相关mschapv2的讲解） 这个包就开始了发送challenge包的处理。 服务端发送mschap-v2的challenge进行挑战处理。服务端发送mschap-v2的挑战后，客户端开始发送AccesRequest的包进行处理 
4
我们打开这个包后，看到客户端发送，我们期望使用PEAP这个协议进行保护传送的信息 
5
服务端进行发挥EAP-TLS的标记，进行开始的处理 这个属性是一个byte分成8位进行表示相关属性 0....... Length Included False .0...... More Fragments False 在下面传证书的时候会需要这个属性，因为一开始EAP的长度是255，HandShake的certificate长度属性是三位，4095的长度。所以需要分段。发送这个请求是1的时候客户端会再次过来请求余下的信息 ..1..... Start True .....000 Version 0
6
重点来了WTF这到底是什么。 首先是一个EAP-TLS flags 然后进行传输。第一个标记是content-Type 告诉服务端这个是handshake的。在这个22的表示时候服务端和客户端都会进行记下这个数据，后面会有使用。 TLS来了 TLS来了，第一个是Client Hello 客户端给服务端发送一个请求并且带着当前客户端支持的tls的版本。服务端的版本必须低于这个版本才能支持。这个时候客户端发送一个随机数我们叫做random1 客户端发送客户端所支持的安全组件。 TLS_RSA_WHITH_AES_256_CBC_SHA 认证算法|RSA | RSA（主流）,DSA,ECDSA 加密算法|ES_256_GCM AES128/256 bit，加密模式gcm/ cbc/ ecb RC4和3DES（不推荐），DES(已淘汰) MAC算法 | SHA256, SHA384, SHA1 密钥交换算法|ECDHE DHE,ECDHE
7
这个是server端发送的server hello的包 server hello 生成一个32位的随机数，并且选择一个加密组件（这个加密组件必须是客户端提供的列表当中）这个时候生成了random2 certificate 发送证书 Server Key Exchange 如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。 Certificate Request Certificate Request 是服务端要求客户端上报证书，这一步是可选的，对于安全性要求高的场景会用到。 这个传输证书就需要了我们上面提到过的TLS-FLAGS的more fragement在经过了三个包陆续把上面的东西发送完成后，我们的server hello 终于完成。  7
客户端发送 Certificate 这个属性是因为我们server端有Certificate Request的属性，需要客户端上传证书。
Client Key Exchange 这个是一个随机数，我们用上一步获取的服务端的公钥证书进行加密，服务端这个时候需要解密这个，算出random3
Encrypted HandShake Message 这个是用master screct + hash+ "client finshed" 生成的一个文字。然后用两边协商好的公钥进行加密。
注意：1）上面的Client Key Exchange 用服务端的私钥解密后产生的是random3，再通过这个算法PRF生成Master Sercet
TlsUtils.PRF(pms, "master secret", TlsUtils.concat(securityParameters.clientRandom, securityParameters.serverRandom), 48);
2）生成Master Sercet 是为了在后面通过对称加密，因为非对称加密非常浪费性能。
3）Encrypted HandShake Message 是通过master secret 加密后的东西。服务端在收到后必先进行解密，然后服务端在根据"client server"生成一个字符串，对比是否想等。
服务端要进行最后一步了Server Done 
9
Server Done ?!哪呢，哪里有ServerDone。
这个server done 是机密服务端存储进去的。客户端需要解密后对比，如果正确，就认为这次握手是成功的。
生成的算法是 Master+hash+"server done"
其中这个hash是记录所有handshake值后计算出来的。所以如果客户端和服务端都收到所有的包后，两边的（这个hash是32位，前16位MD5 后16位SHA1）hash值应该是一样的
这个时候客户端再发送一个EAP-TLS请求表示握手完成。 
10
剩下的包都是application data的包了，各位兄弟，祝你好运，因为这些都是加密后的，wireshark以及无法帮你解包了 
11
剩下的基本都是mschap-v2的流程了，简单说一下就是服务端先给你个随机挑战数，客户端收到后 randomServer+username+password+random2 (peer random) 发送给服务端，服务端收到后再算一遍看看两个是否一样。提醒下这中间的解密，不能漏过任何一个包！！！ 都要解开不要管是否有用，因为TLS为了保证每次对话都双方通过，有个类似于HMAC的，每次都计算出来，然后解密处理。 mschapv2可以参考mschap-v2 radius 代码 jradius 当然啦，JRadius是客户端的代码，服务端自学吧。 |
【本文地址】
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |